❌   Gradle Check failure ce83ed489f4c91184e8822a0c4c726319e71ca7c
Log 5246

Reports 5246

❌   Gradle Check failure 3d97ca1
Log 5248

Reports 5248

✅   Gradle Check success 805305c
Log 5250

Reports 5250

The backport to 2.x failed:

The process '/usr/bin/git' failed with exit code 1

To backport manually, run these commands in your terminal:

# Fetch latest updates from GitHub
git fetch
# Create a new working tree
git worktree add .worktrees/backport-2.x 2.x
# Navigate to the new working tree
cd .worktrees/backport-2.x
# Create a new branch
git switch --create backport/backport-3296-to-2.x
# Cherry-pick the merged commit of this pull request and resolve the conflicts
git cherry-pick -x --mainline 1 3aef125d0dbf2f29d9bf00b84cb52892a27a5328
# Push it to GitHub
git push --set-upstream origin backport/backport-3296-to-2.x
# Go back to the original working tree
cd ../..
# Delete the working tree
git worktree remove .worktrees/backport-2.x

Then, create a pull request where the base branch is 2.x and the compare/head branch is backport/backport-3296-to-2.x.

The backport to 2.0 failed:

The process '/usr/bin/git' failed with exit code 1

To backport manually, run these commands in your terminal:

# Fetch latest updates from GitHub
git fetch
# Create a new working tree
git worktree add .worktrees/backport-2.0 2.0
# Navigate to the new working tree
cd .worktrees/backport-2.0
# Create a new branch
git switch --create backport/backport-3296-to-2.0
# Cherry-pick the merged commit of this pull request and resolve the conflicts
git cherry-pick -x --mainline 1 3aef125d0dbf2f29d9bf00b84cb52892a27a5328
# Push it to GitHub
git push --set-upstream origin backport/backport-3296-to-2.0
# Go back to the original working tree
cd ../..
# Delete the working tree
git worktree remove .worktrees/backport-2.0

Then, create a pull request where the base branch is 2.0 and the compare/head branch is backport/backport-3296-to-2.0.

do we have any tooling (or plans for tooling) that enforce that @opensearch.internal annotated classes aren't used externally?

No... (not yet). For now the only enforcement would be to follow up and refactor any sloppily used modifiers from public to package private or private. I was curious if java annotation enforcement could be a job for the forbiddenAPI? I'm not that familiar with using forbiddenAPIs and if this is the right application of it's services. Maybe java policeman @uschindler has some thoughts?

Hi,
You would need some classfile scanner that produces a forbiddenapis signatures file. For @Deprecated java annotation there is a processor available as Java class with a complementing Groovy script in forbiddenapis to be adapted (replace annotation name and tell it which jar files to scan).

https://github.com/policeman-tools/forbidden-apis/blob/main/src/tools/java/de/thetaphi/forbiddenapis/DeprecatedGen.java

So one could generate signatures files automatically after compile.

The question is more: why would anybody use it in downstream code?

The question is more: why would anybody use it in downstream code?

I'm thinking of it being used in an opensearch plugin specific context. Something like K-NN plugin which now injects a custom codec - whereas before it was overriding the entire engine. There are certain classes we just don't want to be able to override in a downstream plugin. We're getting better about fixing the class modifiers (Elastic never worried about this since it was never a community project) but we have a long way to go. In the meantime I've started liberally applying the @opensearch.internal javadoc annotation to communicate that plugins should not override anything with that annotation.

I wonder if we could enforce this in build-tools without breaking the core build? Build the signature file when build-tools is built and have the downstream plugins consume it during their plugin build?